FinTS Spezifikation mit "Verification of Payee" jetzt veröffentlicht.

Danke für den Link. Ich frage mich, warum dafür ein extra Geschäftsvorfall (schlimm genug) definiert wurde und hierfür auch noch eine extra Request-Response-Schleife bei der Bank-Kommunikation eingeführt wurde (noch schlimmer). Und weil das ganze noch nicht umständlich genug ist, wird mit Opt-In und Opt-Out auch noch zwei verschiedene Varianten eingeführt. Durch das ganze HKTAN-Theater wird ein Auftrag doch ohnehin erstmal nur eingereicht und erst in einem zweiten Schritt freigegeben. Da hätte doch die Bank einfach direkt nach dem Einreichen des Auftrages z.B. als 3xxx-Code eine VOP-Warnung zurückliefern können (von mir aus auch als extra Segment). Basierend darauf hätte der Client abbrechen können. Ich versteh's echt nicht. Die Banking-Anwendung muss jetzt jeden Auftrag zweimal hinschicken. Einmal, damit die Bank danach sagen kann, ob der Namensabgleich ok war und danach noch ein zweites Mal, um ihn tatsächlich einzureichen. Und danach dann die TANs. Jetzt fehlt nur noch, dass für den Namensabgleich nochmal eine extra TAN erforderlich ist.

Ich weiss nicht, ob ich hier irgendwas falsch verstehe. Aber ist hier der langfristige Plan, FinTS so lange mit weiterer Komplexität zuzukleben, bis es nicht mehr praxistauglich nutzbar ist und die User nur noch PSD2-Apps nutzen?

Ich versteh's echt nicht. Jedesmal, wenn man denkt, dass man sich jetzt mal wieder um echte neue Features in der Anwendung kümmern könnte, kommt so eine Spezifikationsänderung. Mit dem Effekt, dass die User eigentlich nie neue Funktionen kriegen oder man mal Sachen grundlegend modernisieren kann.

Und konkret zu VoP: Mir erschliesst sich überhaupt nicht, warum der Ablauf bei Zahlungsaufträgen jetzt generell geändert wurde. In sicher über 95% der Fälle passt doch der Name zum Empfänger und die Extra-Runde in der Bank-Kommunikation führt lediglich dazu, dass das Programm noch länger braucht, um die Überweisung zu senden (ohne dass für den User ein augenscheinlicher Grund ersichtlich ist). Nur in den seltensten Fällen wird es zu einer Auffälligkeit kommen. Und in dem Fall hätte man das genauso handhaben können, wie es bei Doppeleinreichungen von Überweisungen bereits seit jeher die meisten Banken handhaben: Wenn ich eine Überweisung an den selben Empfänger mit dem selben Betrag innerhalb eines (oder X) Tages(n) erneut einreiche, lehnt die Bank es erstmal wegen vermeintlicher Doppeleinreichung ab. Sendet man den Auftrag innerhalb von X Minuten nochmal, nimmt die Bank ihn an, weil davon auszugehen ist, dass es Absicht war. Hätte man mit Namensabweichungen genauso handhaben können. Fertig. Pragmatische Lösung. Seit Jahren bewährt und keinerlei Protokolländerung nötig. Und ich könnte mir vorstellen, dass *nach* Einführung von VoP festgestellt wird, dass das alles eigentlich zu komplex ist und dann am Ende doch noch eine vereinfachte oder nachgebesserte Version kommt. Ich erinnere da an die ganzen Lastschrift-Varianten (FRST,RCUR,LST), die es mal gab.

Das stimmt natürlich. Aber spätestens dort hätte man doch merken müssen, dass die Idee von VoP an sich absurd ist. Aber mich fragt ja keiner ;)

Wäre es aber nicht sinnvoller gewesen, erstmal das Gläubiger-ID-Verzeichnis sichtbar zu machen.

Wirtschafts-Identifikationsnummer (W-IdNr.) kommt ja nun auch noch https://www.bzst.de/DE/Unterne…_node.html
https://www.bzst.de/DE/Unterne…_node.html

Darf ich vielleicht mal eine dumme Frage stellen?
Wie sieht es in Zukunft mit dem Namensabgleich bei Gemeinschaftskonen aus?

Muss man in Zukunft bei Überweisungen auf ein solches Konto beide Namen angeben?
Die werden ja auch bei den Banken teilweise unterschiedlich geschrieben. Mal: Herr Völker Mustermann und Frau Lena Mustermann. Mal: Herr Völker und Frau Lena Mustemann.
Danke +

Was soll dann passieren? Dann ist natürlich nur der Ehemann anzugeben. Wie das "benutzt" wird ist ja wohl völlig irrelevant!? Das Konto hat eine Kontobezeichnung und wenn nur der Ehemann Kontoinhaber ist, dann lautet die auch auf ihn. Ist doch ganz einfach.

Also Lena Musterman dürfte nicht gehen. Das ist ja explizit nicht der Kontoinhaber. Mustermann alleine sollte gehen... Aber man wird wohl abwarten müssen, was da dann am Ende rauskommt. Am sinnvollsten wäre es doch wohl, wenn man genauso wie die IBAN künftig auf seinen Rechnungen auch einen Empfänger angibt, den der Zahler dann 1:1 übernimmt. Aber auf so einfache Lösungen kommt sicher wieder keiner

Und außerdem wird man abwarten müssen, ob das nicht im nachhinein dann wieder verwässert - sprich an die Wirklichkeit angepasst - wird. Ähnlich der Vorlauffristen und Stati bei den SEPA-Lastschriften. Erst wird höchst aufwändig etwas umgesetzt, alle Programmierer arbeiten ewig an der Umsetzung - und dann wird es doch nicht beibehalten und alle Arbeit ist für nix. Abwarten...

Nicht nur Du nicht und die, die gefragt wurden, haben aus einer ganz anderen Sicht geantwortet, weil sie die Konsequenzen aus der Regulationssicht nicht verstanden/nicht gesehen haben.

Die Verordnung sagt, dass VoP durchzuführen ist, vor der Authorisierung und der Anwender auf Basis des VoP Ergebnis entscheidet, ob der Auftrag durchgeführt wird oder nicht. Die Regulatorik sagt auch, dass die VoP in direkten Zusammenhang mit dem Auftrag stehen muss.

Dann gilt für Verbraucher ist VoP verpflichtend. Sprich bei jeder! Überweisung muss eine VoP durchgeführt werden, auch wenn ich schon 100 x an diesen Empfänger überweisen habe.
Für Nichtverbraucher darf der Kunde bei Sammelaufträgen auf eine VoP verzichten. auch dies msus der Kunde bei jeder Überweisung neu entscheiden.

Diese Verordnung gilt für alle Kanäle. Onlinebanking in der App und im Web, FinTS, EBICS, am SB Terminal, am Schalter....
D.h. die Verordnung muss in völlig unterschiedlichen Verfahren umgesetzt werden, so dass es sehr unterschiedliche Voraussetzungen gibt.

FinTS kennt Verbraucher und Nichtverbraucher, d.h. man muss irgendwie der Software mitteilen, ob eine Ausnahme erlaubt ist oder nicht und diese dann auch steuern können. Dann muss man einen Prozess haben, mit dem man zum Prüfen einreichen kann, das Ergebnis abrufen kann und dann den Auftrag einreichen kann. Da die Verordnung einen Zusammenhang verlangt, muss ich sicherstellen, dass es der gleiche Auftrag ist. Da FinTS keine Verteilte EU wie in EBICS kennt, kann ich nichts parken und darauf die Prozesse aufbauen.

Das hier ist auf jeden Fall eine Regulierung, die zumindest am Firmenkunden völlig vorbei geht - auch wenn man wohl deren Vertreter konsultiert hatte und die die Idee des Empfängerabgleichs super fanden (klar, wer möchte seine Daten nicht bereinigt wissen) Die hatten sicher nicht auf dem Plan, dass das bei jeder Transaktion erfolgt, auch wenn die Empfänger schon korrekt sind und es wohl Korrekturen geben wird, sondern nur etwas wie passt, passt gar nicht, oder passt teilweise....

Und natürlich, wenn ich einen Sammler mit 300 Aufträgen einreiche und 4 Aufträge passen teilweise und zwei nicht, oder bei Zweien hat die Empfängerbank nicht schnell genug die Antwort geschickt, darf der Anwender dann überlegen, ob er die 300 Aufträge frei gibt, oder keinen. Wenn dann keiner und die 6 Aufträge werden raus genommen, fängt das wieder von Vorne an, sprich Einreichung zur VoP und dann Freigabe.....

Wer das Alles bis zum Start der Regulierung nicht kann, kann keine Überweisungen mehr ausführen...
Achso, verarbeiten der pain 002 für die Ergebnisse kommen ja auch noch hinzu und wer Mehrfachunterschriften unterstützt bekommt noch mal Spaß.......

Zumal dort diverse Sonderzeichen drin sein könnten die bei Banking nicht unterstützt werden.