Hallo,

ich habe einen Bankzugang bei der Sparkasse Nürnberg. Dort kann man seit dem magischen 14.09. eine sogenannte Whitelist mit Konten erstellen, auf die man dann zukünftig ohne TAN-Eingabe Überweisungen tätigen kann. Über das Webbanking hat das auch schon geklappt.

Jetzt wollte ich auf das gleiche Konto mit Banking4i eine weitere Überweisung tätigen und wurde zur Eingabe einer TAN aufgefordert. In der PushTAN-App lag für diesen Auftrag auch eine TAN vor, obwohl wie oben beschrieben aufgrund des Eintrags in der Whitelist die Überweisung hätte TAN-frei erfolgen sollen.

Liegt hier ein Fehler seitens Banking4i vor oder bezieht sich die TAN-freie Überweisung nur auf das Webbanking?

Schon mal danke für Eure Antworten.

Bezieht sich nur auf das WebBanking. Im HBCI-Protokoll sind Überweisungen ohne TAN-Eingabe nicht vorgesehen. Deswegen wird ja auch bei Freigabeverfahren, die im WebBanking nur einen Klick auf "Ausführen" vorsehen (z.B. via App oder BestSign bei der Postbank) im Falle HBCI eine TAN angezeigt und muss diese eingegeben werden. Somit "alles normal" in B4.

Danke für die Antwort. Aber ich muss leider doch widersprechen. Es funktioniert jetzt doch!

Ich hatte es nochmal mit einer Terminüberweisung über das Webbanking probiert und wurde wieder zur TAN-Eingabe aufgefordert. In den Einstellungen stellte ich dann fest, dass die TAN-freie Überweisung deaktiviert war. Ich hatte das nicht selbst ausgeschaltet. Keine Ahnung, weshalb die Sparkasse diesen Punkt einfach deaktiviert hat.

Ich schaltete den Punkt wieder mit einer TAN frei und testete noch einmal mit Banking4i. Und siehe da, das Ganze ging ohne TAN durch.

Hätte ich zuvor im Onlinebanking nachgesehen, hätte sich meine Frage erübrigt. Aber wer rechnet schon damit, dass seitens der Bank einfach ungefragt Einstellungen verändert werden? Wenn das nochmal vorkommt, werde ich mich bei der Bank beschweren.

Sappralott. Man lernt nie aus. Ich konnte auch gerade via HBCI eine Terminüberweisung ohne TAN einreichen auf eine IBAN, die ich vorher für TAN-frei erfaßt hatte. Nachdem das klappt, frage ich mich, wieso das dann bei den genannten Freigabeverfahren nicht ohne TAN-Eingabe klappt... seltsam.

Lustig: Für die anschließende Stornierung der TAN-freien UW mußte ich dann eine TAN eingeben

Ja stimmt, für die Stornierung benötigte ich auch eine TAN. Aber auf den zweiten Blick ist das schon sinnvoll. Dann wäre ein Hacker nicht in der Lage, ohne mein Wissen Terminüberweisungen zu löschen. Da die Sparkasse gott sei Dank die PSD2-Richtlinie großzügig handhabt und nicht für jedes Login eine TAN verlangt, ist das dann schon OK.

Klar, ich bin mit der Umsetzung der FI und auch von Fiducia&GAD auch völlig einverstanden! Damit kann man leben und es steigert in gewissem Maße die Sicherheit. So wie es Consors umgesetzt hat verringert es die Sicherheit, weil der Kunde bald nicht mehr drüber nachdenkt, wann und warum er TANs eingibt sondern es einfach unreflektiert tut.

Nur zur Klarstellung für andere:
Die Software (egal welche) hat darauf keinen Einfluss. Jede Software, die seit der PSD2 noch funktioniert, kann das. Ob die TAN notwnedig ist oder nicht entscheidet ausschliesslich die Bank. Keine Software kann das beeinflussen.

Ich wollte gestern/heute eine Überweisung in Banking4A vom Tagesgeldkonto aufs Girokonto durchführen, beide Konten bei der Triodos (nutzt Fiducia). Eine MTAN wurde angefordert, es kam eine SMS, doch nach der Eingabe legte sich Banking4A auf die Nase: The server returned an invalid or unrecognized response.

Im Webinterface war dann die Überweisung ohne TAN-Eingabe möglich, sollte sie eigentlich auch per HBCI möglich sein und Banking4A hat dabei irgendwas vertüddelt?

Den Banking4-Support habe ich jedenfalls auch mal kontaktiert.

VG

Hast Du das als normale Überweisung gemacht oder als Umbuchung? Mit dem Geschäftsvorfall Umbuchung habe ich solche Transfers bereits erfolgreich durchgeführt - wenn ich mich recht erinnere ohne TAN.

Als Umbuchung. Eine Umbuchung vor 14 Tagen lief auch problemlos mit TAN durch.

Update: Es gab mittlerweile ein Bugfix-Release seitens @subsembly, Problem tritt aber leider weiterhin auf. Die Stornierung eines Dauerauftrages führte im Übrigen auch zu der Fehlermeldung.