Aktuelle Situation bei PSD2

[#1]

Bisweilen kann ich die hier geführten Diskussionen „EBICS oder HBCI“ nur begrenzt nachvollziehen. Welches Verfahren besser oder schlechter ist spielt doch in vielen Betrachtungen gar keine oder nur eine untergeordnete Rolle. Fakt ist, es gibt mehrere Verfahren, von denen DATEV nicht alle unterstützen kann. Warum das so ist? Darauf wurde ja schon an vielen Stellen hingewiesen.

Ich würde gerne zwei Sachverhalte unterscheiden:

Einsatz von DATEV Zahlungsverkehr
Vor vielen Jahren hat sich DATEV entschlossen, das Programm dahingehend zu verändern, dass die direkte Kommunikation zu den Banken nicht mehr unterstützt wird, sondern immer das DATEV Rechenzentrum zwischengeschaltet sein muss. Heute, mehr als 15 Jahre später, bestand die Möglichkeit die Softwarelösung zu „korrigieren“. Software wie SFirm, Profi cash oder StarMoney funktionieren losgelöst von Rechenzentren. Bei DATEV Zahlungsverkehr wäre nur der Übertragungsweg der Zahlungen und der Kontoabruf zu ändern.

Darauf hat DATEV verzichtet und muss sich heute den Spott und Hohn gefallen lassen der über die Genossenschaft ergeht. All die Fragen, die an verschiedenen Stellen beschrieben und diskutiert wurden, wären aus meiner Sicht vollkommen überflüssig, hätte sich DATEV für eine Lösung, losgelöst vom RZ entschieden.

Den Fehler bei Banken zu suchen, halte ich für wenig zielführend. Wir wissen aus der Vergangenheit, dass dort jeder sein eigenes Süppchen kocht, das wir und unsere Kunden dann auslöffeln können.

Einsatz von Bank online / Unternehmen online
Hier handelt es sich um online-Anwendungen, bei denen ich nachvollziehen kann, warum DATEV den Weg über finAPI gehen muss. Aber eine Schufa-Tochter, bestehend aus 25 Mitarbeitern, mit dieser Aufgabenstellung zu beauftragen … sehr spannend!!! (Ich weiß, dass es nur wenige Alternativen gibt)

Ergebnis:
Ich habe diese Woche bei zwei Mandanten auf finAPI umstellen müssen und kann bis jetzt sagen: KATASTROPHE

Es ist mir absolut unverständlich, wie man eine so weitreichende Umstellung derart amateurhaft angehen kann. Von DATEV gab es unendlich viel Informationen. Wie immer sehr gut aufbereitet und verständlich erklärt. Was aber ist im Hintergrund passiert? Hatte man im Vorfeld nicht genügend Zeit die unterschiedlichen Szenarien zu testen? Stattdessen werden unsere Mandanten als Versuchskaninchen missbraucht.

Wie geschrieben habe ich 2 Mandanten umgestellt und bin dabei über 5 Fehler gestolpert. Sicherlich auch kleine Fehler, die man großzügig übersehen kann. Ein Fehler führte jedoch dazu, dass trotz Fehlermeldung von DATEV/finAPI eine Sammelzahlung versendet und von der Bank ausgeführt wurde. Da dies nicht zu erkennen war, hat der Mandant die Zahlung auf einem anderen Weg erneut angestoßen und damit die Zahlungen doppelt auf den Weg gebracht.

Hätte der Mandant das sehen können? Ganz klar NEIN.

Auch einer hilfsbereiten DATEV-Mitarbeiterin im Support war nicht klar, dass der Auftrag trotz Fehlermeldung durchgegangen ist.

Ich bin gespannt was in den nächsten Tagen und Wochen noch alles passiert. Die armen Mitarbeiter im DATEV-Support werden sich sicherlich viel anhören müssen. Mein Mitgefühl haben sie. 

Ein sonniges Wochenende

Jens Held

[#2]

... obwohl es uns in der Banking-Praxis nichts hilft, ist es doch interessant zu sehen, wie klein doch der 'erlauchte Kreis' der KIDLs und ZADLs immer noch ist (siehe hier: Diese deutschen Fintech-Startups haben eine PSD2-Lizenz von der Bafin ).

Warum die Datev in diesem Grüppchen nicht 'mitspielen' wollte oder durfte, wissen nur 'die Götter'.

Aber warum sich die Banken nicht gegenseitig die Zugriffsmöglichkeiten gewähren, z.B. innerhalb der "Berlin Group" (the-berlin-group), obwohl sie offenbar 'von Haus aus' die Bafin-Erlaubnis dazu hätten, ist mir wirklich ein Rätsel.

VG

Michael Vogtsburger

[#3]

Frage an DATEV: Hätte DATEV nicht ein eigenes kleines „Zahlungsverkehrs“-Tochterunternehmen gründen können, das die BAFIN-Zertifizierung beantragt? Dann hätte nicht die gesamte DATEV e.G. die Zertifizierung durchmachen müssen. Hätte man damit nicht alles selbst in der Hand gehabt?

[#4]

Hallo Herr Konerding,

wenn sich die DATEV selbst zertifizieren hätte lassen, bzw. wie von Ihnen vorgeschlagen ein Tochterunternehmen gegründet hätte, würden nach wie vor die gleichen Einschränkungen und Bedingungen gelten, wie jetzt auch mit dem Partner und Drittdienstleister finAPI GmbH. Die potentiellen Einschränkungen, die das Gesetz mit sich bringt, würden auch trotz Tochterunternehmen bestehen.

Mit freundlichen Grüßen

Michelle Eichner

Produktmanagement Zahlungsprozesse

[#5]

Hallo Frau Eichner,

das stimmt, aber man hätte nicht das ungute Gefühl das aktuell mitschwingt wenn man "Teil der SCHUFA-Gruppe" liest..

Viele Grüße

Marc Brost

[#6]

die Hauptdiskussion ging doch bisher eher Richtung Funktionen.

Dh. lediglich eine Mitbewerber wie Figo o.ä. wäre dann eine Alternative gewesen (also startup), anstatt es selbst zu machen - siehe Kosten.

[#7]

Hallo Frau Eichner,

man hätte zwar vermutlich die gleichen Probleme mit den neuen Banking-Schnittstellen, aber es macht schon einen Unterschied, ob man solche technischen Probleme 'im Haus' bearbeitet oder ob man sich immer wieder mit einem Fremdunternehmen austauschen, kurzschließen und abstimmen muss.

Leider reagieren die diversen Schnittstellen zwischen Datev und finAPI und zwischen finAPI und den Banken offenbar nicht richtig bidirektional, sondern so ähnlich wie beim Spiel "Stille Post".

Die Verbindung zwischen Datev und den Banken reißt während des Zugriffs ab bzw. es gibt offenbar keine korrekten Rückmeldungen zum Status des Banking-Prozesses.

VG

Michael Vogtsburger

[#8]

Hallo Herr Ettl,

wir verarbeiten in unseren DATEV-Anwendungen ausschließlich Kontoumsätze die im MT940-Format von den Banken kommen.

Das MT942-Format, was auch einen "Echtzeitkontoumsatzabruf" beinhaltet, wird von uns nicht unterstützt.

Ich werde Ihren Wunsch dazu mit in die Produktplanung aufnehmen.

Mit freundlichen Grüßen

Jeannine Schäffler

Produktmanagement Zahlungsprozesse

[#9]

Hallo liebe Community,

„Hätte hätte Fahrradkette“;-) ich bin mal so frei und bringe das mal so salopp auf den Punkt, denn: wir haben die Entscheidung für die Integration eines Drittanbieters und die Wahl auf finAPI unter der zu diesem Zeitpunkt bekannten Rahmenbedingungen getroffen. Hätten wir bspw. vorhersehen können dass es eine Reihe an funktionellen Einschränkungen im Vergleich zu heute gibt, die pro Bank dann noch unterschiedlich gehandhabt werden können, hätten wir gewusst dass die Tests mit Drittanbietern und den Banken eine derartige Verschiebung aufweisen (siehe Gründe und Details im Artikel im Post zur Aktuellen Situation), hätten .... wer weiß wie wir uns dann entschieden hätten.

Zum damaligen Zeitpunkt mit den uns vorliegenden Informationen haben wir uns m.E. richtig entschieden. Eines war uns wichtig: Das Übermittlungsverfahren mit einer PIN und einer TAN für Sie aufrecht zu erhalten und weiterhin als das kostengünstigste Verfahren für die Übermittlung von Zahlungen und Kontoumsätzen anzubieten.

Wir aktualisieren laufend unter www.datev.de/zag um neue Informationen, in dem wir diese unter “Aktuelle Meldungen“ veröffentlichen. Wir würden uns freuen wenn Sie dort einen Blick drauf werfen, gerne Ihr Feedback dazu.

Über einen weiteren interessanten Austausch mit Ihnen freut sich

Bianca Krach

[#10]

Ein Echtzeitabruf ist also möglich? Bitte meinen Wunsch hinzufügen... Schon nervig, dass man immer einen Tag warten muss...

[#11]

war nicht mal die Rede, dass auf camt umgestellt wird?

[#12]

„Hätte hätte Fahrradkette ...“

... schon klar, dass man jetzt nicht so einfach wieder switchen und die letzten paar Monate "auf Anfang zurückspulen" kann.

Alle Beteiligten woll(t)en ja nur das Beste (für sich) .

... nur mal interessehalber eine rhetorische Frage .... :

Ist die Datev jetzt bis auf unbestimmte Zeit oder für eine längere Mindestlaufzeit mit der finAPI "verheiratet" ?

Falls nein, hätte die Datev vermutlich aber trotzdem momentan keine bessere Alternative "im Ärmel", denn das Entwickeln eigener Banking-Schnittstellen dürfte auch für die Datev trotz ihrer vielen Software-Entwickler ein großes Problem sein, mangels Fachwissen in diesem speziellen Bereich.

Die Datev ist glücklicherweise nicht der Urheber der PSD2-Probleme, sondern gehört selbst zu den Betroffenen und Geschädigten.

Aber was jetzt unbedingt gut kommuniziert werden muss ... sind Notlösungen und Hinweise zur Fehlervermeidung.

VG

Michael Vogtsburger

[#13]

Hallo Herr Heine,

mit der SEPA-Einführung 2014 wurde bei den Banken das Format SWIFT-EDIFACT durch camt ersetzt. Die Banken hatten mitgeteilt, dass sie die in SWIFT enthaltenen MT-Formate in der Kommunikation mit den Kunden nicht mehr unterstützten wollen. Aktuell wird camt meines Wissens nur im Bereich der Geschäftskunden (auf Anfrage) angeboten.

Beste Grüße

Andreas Briefs

[#14]

Ich werde Ihren Wunsch dazu mit in die Produktplanung aufnehmen.

Hallo Frau Schäffler,

wir haben den selben Wunsch wie Herr Böhnke, bitte uns ebenfalls für diesen Wunsch vermerken.

Viele Grüße

Marc Brost

[#15]

Hallo Frau Krach,

.... wer weiß wie wir uns dann entschieden hätten.

Noch ist nicht aller Tage Abend, die Datev kann ja nach wie vor eine eigene Schnittstelle aufsetzen und diese ihren Nutzern dann zur Verfügung stellen, also ist nichts verloren Man kann diese Idee ja mal im Hinterkopf behalten und im Falle des Falles angehen falls man von der finAPI keine Zusicherung erhält, dass die Daten nicht an die SCHUFA weitergegeben werden, das steht soweit ich weiß noch nach wie vor aus.

[#16]

Hallo Herr Briefs,

die Onlinebanking-Anwendungen (Software) arbeiten zwischenzeitlich alle mit camt bzw. rufen diese auch so ab, das fallback und veraltet ist MT...

siehe auch als Kurzinfo: Camt-Format – Wikipedia

dh. es steht selbstverständlich auch Privatkunden schon länger zur Verfügung

[#17]

Hallo Herr Heine,

Zitat aus dem von Ihnen erwähnten Wikipedia-Artikel:

     In Online-Programmen für den Privatkundenbereich stehen

     diese Formate meist nicht bereit.

Das mag von Bank zu Bank bzw. von Region zu Region aber auch unterschiedlich gehandhabt werden.

Beste Grüße

Andreas Briefs

[#18]

Hallo Herr Heine,

in der o.g. Quelle steht ...

In Online-Programmen für den Privatkundenbereich stehen diese Formate meist nicht bereit.

Egal,

Kann denn Datev-REWE mit dem CAMT-Format etwas anfangen ?

... ist mir noch nicht begegnet, sondern immer nur das MT940-Format.

Solange ein Format funktioniert, ist es mir 'schnuppe', ob es schon alt oder gar 'altmodisch' ist.

Von diversen Banken werden auch Exporte im "XML"-Format angeboten.

Aber wenn dieses "XML"-Format genauso wenig standardisiert ist wie das "CSV"-Format, fasse ich solche Dateien besser nicht an.

VG

Michael Vogtsburger

Nachtrag: ...ups, wer zu spät kommt, den bestrafen die (schnelleren) Posts

[#19]

dann muss der Artikel überarbeitet werden

und der Augenmerk zum damaligen Zeitpunkt liegt auf meist

Bitte prüfen Sie Ihre Software

changelog-Infos: (exemplarisch)

selbst Opensource-Software berücksichtigt es:

https://www.willuhn.de/wiki/doku.php?id=handbuch:umsaetze#konto-umsaetze_im_neuen_sepa-format_camt

oder Starmoney: Die StarMoney Community - Suche

oder VR-NW: seit Software Version 5.12 24.06.2014​

für weitere Infos, wende Sie sich doch ein Fachforum bspw: https://homebanking-hilfe.de/forum/

bzw. an die technische Fachabteilung Ihrer Bank

[#20]

Streit über Kontoschnittstellen eskaliert

Eine junge Finanzfirma bemängelt in einem Brief die Kontoschnittstellen der deutschen Geldhäuser. Diese wehren sich gegen die Kritik des Fintechs. Handelsblatt

[#21]

Hallo Herr Vogtsburger,

Kann denn Datev-REWE mit dem CAMT-Format etwas anfangen ?

momentan noch nicht:  Kontoauszugsformat CAMT

Beste Grüße

Andreas Briefs

[#22]

Hallo Community,

ich will das schöne Statement von biancakrach​

am derzeitigen Ende des Threads PSD2 - "heißer Brei" oder "kalter Kaffee" ?

nicht stören, deshalb stelle ich hier mal eine kleine Verständnisfrage:

Sind denn tatsächlich alle RZ-Bankinfo-Umsatzabrufe nicht betroffen von PSD2 ?

Ich habe bisher nämlich (noch) keine Probleme mit finAPI & Co

Apropos finAPI:

kommt eigentlich finAPI auch bei RZ-Bankinfo (durch die Hintertür) in´s Spiel oder macht dieser Weg einen großen Bogen um die Schufa(tochter) ?

VG

Michael Vogtsburger

[#23]

EBICS und RZ dürften "ähnlich" sein und somit von der PSD2 ausgenommen.

[#24]

Sehr geehrte Frau Krach,

ich nutze für die Kanzlei selbst derzeit noch einen HBCI-Zugang - die Umstellung auf EBICS läuft gerade.

Wo genau erkenne ich, ob mein HBCI-Zugang bereits von Datev auf "nicht initialisiert" gesetzt wurde? Es funktionieren keine Lastschrifteinzüge mehr, aber nirgends erscheint ein Hinweis, dass die Umstellung erfolgt ist

Vielen Dank für eine zeitnahe Rückmeldung.

[#25]

Hallo Community,

ich will das schöne Statement von biancakrach

am derzeitigen Ende des Threads PSD2 - "heißer Brei" oder "kalter Kaffee" ?

nicht stören, deshalb stelle ich hier mal eine kleine Verständnisfrage:

Sind denn tatsächlich alle RZ-Bankinfo-Umsatzabrufe nicht betroffen von PSD2 ?

Ich habe bisher nämlich (noch) keine Probleme mit finAPI & Co

Apropos finAPI:

kommt eigentlich finAPI auch bei RZ-Bankinfo (durch die Hintertür) in´s Spiel oder macht dieser Weg einen großen Bogen um die Schufa(tochter) ?

VG

Michael Vogtsburger

EBICS und RZ-Kontoabruf sind nicht von der PSD2 betroffen.

Es geht in der Richtlinie um die Erhöhung des Verbraucherschutzes. Alle Verbraucher nutzen ein HBCI-Banking, deshalb ist dieses bei der Umstellung auch im Fokus und alles andere wie EBICS nicht. Auch nicht in Zukunft durch die Hintertür.

Gruß

Tobias Ettl

[#26]

HBCI > FinTS

genau genommen heißt FinTS-Banking

Im Jahr 2002 ist HBCI im "Financial Transaction Service" (FinTS) aufgegangen. Dieser Standard bietet gegenüber den HBCI-Vorgängern zusätzliche Möglichkeiten: So können OnlineÜberweisungen seitdem nicht nur mit der generell üblichen elektronischen Signatur, sondern auch mit dem Sicherheitsverfahren PIN/TAN beauftragt werden. Mehr Sicherheit gibt es beim FinTS-Standard, weil mit ihm die verwendeten elektronischen Schlüssel verlängert wurden - von 1024 auf 2048 Bit.

[#27]

Sehr geehrte Frau Hentschel,

vielen Dank für Ihre Frage.

Ich nehme an Sie nutzen den Zahlungsverkehr on premise. In diesem Programm bestimmen Sie den Umstellungszeitpunkt selbst.

Ich entnehme Ihrer Aussage, dass Sie in der Kanzlei auf EBICS umstellen wollen, kann aber nicht ausschließen dass Sie ggf. mindestens 1 HBCI-Benutzer bereits auf finAPI umgestellt haben, daher der nachfolgende Absatz zur Sicherheit:

Besonderheit bzgl. "Umstellungszeitpunkt selbst wählen" - nur relevant sofern Sie im Zahlungsverkehr on premise bereits 1 HBCI-Benutzer auf finAPI umgestellt haben:

Alle HBCI-Benutzer, auch unterschiedlichster Berater-/Mandantennummern, müssen in einem Datenbestand zum gleichen Zeitpunkt umgestellt werden, denn nach der Umstellung des ersten HBCI-Benutzers auf das neue PIN/TAN-Verfahren (Drittanbieter-Schnittstelle) oder bei Neuanlage eines HBCI-Benutzers über finAPI, werden alle weiteren HBCI-Benutzer im Datenbestand des Programms Zahlungsverkehr mandantenübergreifend auf „nicht initialisiert“ (inaktiv) gesetzt.

Dazu weißen wir an allen relevanten Stellen hin, u.a. im DATEV Zahlungsverkehr mit einem Warndreieck während der Umstellung des 1. HBCI-Benutzers auf finAPI wie oben beschrieben.

Sie erkennen, ob im Zahlungsverkehr on premise der o. g. Fall mit der Nicht-Initialisierung eingetreten ist, in dem Sie das Symbol HBCI in der Spalte DFÜ Typ nicht mehr sehen.

Voraussetzung für einen Umstieg auf die neue PIN/TAN-Schnittstelle mit finAPI und den oben beschriebenen Fall ist eine vorangegangene Installation des Programmes DATEV Zahlungsverkehr 7.6 (Programm-DVD 12.1, Januar 2019) und die am 09.08.2019 bereitgestellten Service-Releases Zahlungsverkehr 7.69

und SEPA-Basis 2.66.

Bitte beachten Sie bei Ihrem Umstellungsfahrplan auf EBICS:

Spätestens bis 9. September müssen Sie alle HBCI-Benutzer auf EBICS umgestellt haben, damit Sie weiterhin Zahlungen ausführen und Kontoumsätze abholen können.

Details zur Umstellung auf EBICS finden Sie in unserer Checkliste unter https://www.datev.de/web/de/media/datev_de/pdf/sonstige_pdfs/umstieg_ebics-2.pdf

Ich hoffe, Ihnen damit geholfen zu haben.

Beste Grüße

Bianca Krach

[#28]

Ich werde Ihren Wunsch dazu mit in die Produktplanung aufnehmen.

Hallo Frau Schäffler,

wir haben den selben Wunsch wie Herr Böhnke, bitte uns ebenfalls für diesen Wunsch vermerken.

Viele Grüße

Marc Brost

Bitte mich auch mit aufnehmen. Vielen Dank.

[#29]

Eine Antwort auf meinen Service-Kontakt als kurzes Update zu meinem Lastschriften-Problem:

der Fehler bezüglich der Firmenlastschriften, welche nicht über das neue HBCI-Verfahren mit unserem Drittanbieter finAPI an die Bank übermittelt werden konnten, ist bereinigt. Sie können nun wie gewohnt Firmenlastschriften an die Bank senden. Dies betrifft sowohl das Programm Zahlungsverkehr, als auch Bank online.

Wichtig: Bitte beachten Sie, dass es erforderlich ist, vor dem Senden der Firmenlastschrift eine Umsatzabfrage zu starten. Hierbei wird die Berechtigung des HBCI-Users im Hintergrund aktualisiert.

Wir bedanken uns für Ihre Geduld.

[#30]

Hallo Frau Karch,

FINAPI hat meist optimal und einfach funktioniert. Leider gibt es aber auch Probleme, die bis heute nicht gelöst sind.

Wir haben einen Mandanten mit Fremdwährungen / Mulitiwährung...Hilft da EBICS?

wenn EBICS, ist dann eine Umsatzabholung und Zahlungsverkehr für Fremdwährungen bzw. Multiwährungskonten möglich? Wie haben seit August Probleme mit der Deutschen Bank. Der Mandant hat eine Euro, britische Pfund und USD-Konto. Er kann keine Umsätze von der Bank abholen und natürlich auch nicht zahlen. Umstieg auf FINAPI wurde gemacht, funktioniert aber für KEIN Konto.

Frage: Wenn der Kunden nun EBICS nimmt, kann er a) alle Konten sehen und b) auch zahlen? Sorry aber wie sind hier seit Monaten mit DATEV im Gespräch und keiner kann was genaues sagen...

Wie SIEHT eine flexbile und schnelle Lösung aus? Kontomodell umstellen?

Besten Dank in die Runde....Ritz