Automatisierung im Zahlungsverkehr: pain.002 und die korrekte Zuordnung zur pain.001

Viele Banken stellen den pain.002-Payment-Status-Report (PSR) bereits seit Längerem zur Verfügung. Spätestens jedoch mit der Verpflichtung aus der Instant-Payments-Regulation (IPR), Kunden über den Ausführungsstatus jeder einzelnen Zahlung zu informieren, gewinnt die pain.002 zunehmend an Bedeutung.

Je nach Bank bieten diese den pain.002-PSR nicht nur für die Echtzeitzahlungen an, sondern auch für den xml-Auslandszahlungsverkehr, Lastschriften und SEPA-Überweisungen. Die Bereitstellung wird bei EBICS über jeweils unterschiedliche Auftragsarten / BTF zur Verfügung abgeholt.

Die in der Anlage 3 des DFÜ-Abkommens definierten Auftragsarten sind wie folgt:

Zuordnung und Mapping zwischen pain.001 und pain.002

Der PSR gibt Auskunft über den Verarbeitungsstatus der Zahlungen in der pain.001 bei  der Auftraggeber-, aber auch bei  der Empfängerbank. Die detaillierte Zuordnung des Ausführungsstatus zur Einzelzahlungen in der ursprünglichen pain.001 funktioniert nicht ganz automatisch. Der folgende Text gibt Aufschluss über die Fallstricke und Lösungsansätze für eine bessere Verarbeitung.

Wie sind die beiden Dateien miteinander verbunden?

Die pain-Dateien müssen sowohl auf Dateiebene selbst, auf Sammler-Ebene aber auch auf Einzelsatzebene verbunden sein, damit eine korrekte Zuordnung und Auswertung erfolgen können.

Zuordnung auf Datei-Ebene

Die pain.001 ist chronologisch zuerst vorhanden. Deren Daten müssen sich also in der pain.002 wiederfinden, damit die Verbindung zwischen den beiden funktioniert.

Im folgenden Bild ist die pain.001 links und die pain.002 rechts dargestellt.

Auf Header Ebene ist vor allem die Zuordnung des Tags <MsgId> wichtig, die die Zahldatei eindeutig identifiziert. Die <MsgId>in der pain.001 wird zur <OrgnlMsgId>. (Die pain.002 hat übrigens auch eine eigene <MsgId>, vergeben von der Bank)

In der folgenden Abbildung korrespondiert die <MsgId>1008923225</MsgId> aus der pain.001 (links) mit der <OrgnlMsgId>1008923225</OrgnlMsgId> aus der pain.002 (rechts).

Durch das Mapping mittels der <MsgId>/<OrgnlMsgId> finden die beiden Dateien zueinander.

Zuordnung auf Sammler-Ebene

Eine Ähnliches Mapping wie das auf Datei-Ebene muss hier noch zweimal stattfinden. Auf Ebene des Sammlers mittels der Tags <PmtInfId> / <OrgnlPmtInfId >.

Zuordnung auf Einzelsatz-Ebene

Auf Ebene der Einzeltransaktion findet das Mapping mittel <InstrId> / <OrgnlInstrId> und/oder <EndToEndId> / <OrgnlEndToEndId> statt.

Und genau hier liegt eines der größten Probleme:

Die InstrID ist kein Pflichtfeld in der pain.001 und muss somit nicht gesendet werden. Und was die Bank vom Zahler nicht erhält, kann sie nicht korrekt zurückgeben und somit nicht bei der (automatischen) Zuordnung verwenden.

Die EndToEndID wiederum ist ein Pflichtfeld, kann aber immer mit „NOTPROVIDED“ belegt werden und ist in diesem Fall auch ungeeignet, um ein eindeutiges Mapping vorzunehmen. Außerdem ist nicht sichergestellt, dass die Bank die EndToEndID immer mit zurückliefert.

Und wenn beide Tags in der pain.001 nicht vorhanden beziehungsweise nicht ein-eindeutig sind, ist es nicht möglich, die richtige Einzelzahlung zu identifizieren. Ein manueller Abgleich könnte über IBAN und Betrag stattfinden, aber auch hier ist keine Eindeutigkeit garantiert.

Somit muss der Sender der Zahlung sicherstellen, dass die pain.001 nicht nur die Minimum-Voraussetzungen erfüllt, sondern auch für jede einzelne Zahlung unbedingt eine ein-eindeutige InstrID mitsenden, damit die Status-Informationen auf Einzelzahlungsebene aus der pain.002 der ursprünglichen Zahlung gegenüberstellt werden kann. Diese Eineindeutigkeit ist zwingend zu beachten, wenn die Zahlung mit InstrID initiiert wird, da es sonst schon bei Initiierung zur Ablehnung bei der Hausbank kommt. Jede InstrId darf also pro Sammler nur einmal vorkommen, Duplikate führen zur Ablehnung der pain.001.

Sind die Voraussetzungen gegeben, kann ein gutes Electronic-Banking-Programm den Status auf Datei-, Sammler- und Einzelsatz aktualisieren und dem User transparent darstellen, welche Zahlungen gegebenenfalls nicht ausgeführt wurden.

Status-Codes¹

Aufgrund unterschiedlicher betrieblicher Prozesse bei dem Zahlungsdienstleistern (ZDL) und dem Kunden obliegt es der Vereinbarung zwischen ZDL und dem Kunden, wie, ob, wann und welche der folgende Positiv-Codes verwendet werden. Bei Verwendung mehrerer Positiv-Codes bedeutet dies, dass mehrere aufeinanderfolgende pain.002-Nachrichten an den Kunden versendet werden.

Allerdings gilt die grundsätzliche Regel, dass diese optional und nur nach bilateraler Vereinbarung verwendbaren Codes NUR in der hier dargestellten Reihenfolge vorkommen können. Davon bleibt unberührt, dass für einen Fall auch Codes übersprungen/ausgelassen werden können:

Folgende Codes können aufgrund betrieblicher Prozesse unterschiedlich gesetzt werden. Hier ist das grundsätzliche gemeinsame Verständnis in den Regularien der DK beschrieben. Sie sind jedoch insbesondere zu jedem Zeitpunkt möglich. Es ist keine Reihenfolge definiert, jedoch ist die Spalte „Regelwerk der Verwendung“ zu beachten.

Der Status auf Datei-Ebene

Wenn alle Einzelsatz-Rückmeldungen identisch sind, dann trägt die pain.002-Datei diesen Status auch auf Header-Ebene – bestenfalls also „ACCP“. Dann ist klar, dass alle Zahlungen ausgeführt wurden.

Hier ist anzumerken, dass in diesem Fall keine Details zu den Einzelsätzen geliefert werden. Die pain.002 ist verhältnismäßig kurz und gibt eine pauschale Rückmeldung nur auf Datei-Ebene. Da alle Einzelsätze verarbeitet wurden ist es nicht notwendig, diese nochmals im Detail aufzuführen.

Haben alle Einzelzahlungen den Status „RJCT“ kann man dies auch auf Header-Ebene mit demselben Status erkennen. In diesem Fall werden die Einzelzahlungen mit Details der Zahlung und den jeweiligen Ablehnungsgründen zurückgemeldet.

Sind die Status der Einzelzahlungen nicht einheitlich, also einige auf ACCP, andere auf RJCT, dann findet sich auf Header-Ebene der Status PART. Für die abgelehnten Zahlungen werden Details gemeldet.

Rückmeldung auf Einzelsatzebene

Im Normalfall werden für die nicht-akzeptierten Einzelsätze (Status ≠ ACCP) Details aus der Originalzahlung zurückgeliefert. Somit kann man also in der pain.002 im Tag erkennen, welcher Empfänger mit welcher IBAN welchen Betrag hätte erhalten sollen. Deshalb sollte man aus Gründen des Datenschutzes darauf achten, dass nur Mitarbeiterinnen und Mitarbeiter Zugriff auf die pain.002 bekommen, die auch die eigentliche Zahlung einsehen dürfen. Besonders bei Gehaltszahlungen ist hier ein gutes Berechtigungskonzept erforderlich.

Im Umkehrschluss werden für akzeptierte Zahlungen (Status = ACCP) keine weiteren Informationen mehr zurückgeliefert. Diese tauchen in den Details der pain.002 gar nicht mehr auf. Somit hat man bei den akzeptierten Einzelzahlungen auch kein Datenschutzproblem!

Diejenigen Einzelzahlungen, die in den Details der pain.002 nicht mehr gelistet werden sind jene, die ausgeführt wurden.

Zusatzinfo der Ablehnung

Vor allem beim Status RJCT sind die Reason Codes () und die darunter stehen Zusatzinfos () hilfreich bei Fehleranalyse.

Die Inhalte im Feld sind von der DK (in der Anlage 3 des DFÜ-Abkommens) standardisiert, die Texte im Feld sind eher als Prosa zu verstehen.

Die vorgenannten Code-Definitionen können von denen der DK abweichen, wenn es sich um Zahlungskonten außerhalb Deutschlands handelt, die nicht unter dem Reglement der DK sind.

Zusammenfassung

Eine funktionierende pain.002-Interpretation wird in Zukunft unerlässlich sein. In nächster Zeit werden die Echtzeitzahlungen deutlich zunehmen, aber erste Erfahrungen zeigen, dass die Zahl der Abweisungen aktuell noch relativ hoch ist. Wer dann die pain.002 von Hand auswerten muss, weil es das Bankprogramm nicht kann (entweder weil es grundsätzlich dafür nicht konzipiert ist oder weil die pain.001 nicht die notwendige InstrId geliefert hat), der fährt ein gewisses Risiko.

Wer aber mit der Verarbeitung der pain.002 für die Echtzeitzahlungen und dem daraus resultierenden Informationsgewinn zufrieden ist, kann diesen Service auch für anderen Zahlungsarten bei seinen Banken anfragen.

Wichtig ist auf jeden Fall die Befüllung des Feldes <InstrID>, damit der Abgleich zwischen Zahldatei und Statusreport auch auf Einzelsatzebene funktioniert.