Gibt es bereits einen Anbieter der eine einfach Web-Schnittstelle zum ausführen von HBCI/PinTan Vorgängen bietet?

Wenn nein, besteht ein Interesse, dass so etwas entwickelt wird. Ich denke dabei an einen Server auf dem HBCI4Java läuft und welcher auf Web-Schnittstelen anfragen reagiert und entsprechende Daten ermittelt. Das lästige verwalten der Bankeneinstellungen könnten dann einmalig gelöst werden.

Wie seht ihr das?

Sehr sehr großes Interesse meinerseits!!
Ich suche soetwas auch. Am liebsten so geartet, dass es auf Windows und Linux Webservern läuft.
Und in einem späteren Schritt wäre auch eine EBICS Unterstützung wünschenswert.
Bist Du selbst coder?

Ja, ich bin Programmierer und wir erstellen gerade eine Anwendung wo wir Zugriff auf Bankdaten brauchen. Da es ansonsten mittlerweile für so ziemlich alles gute Web-APIs gibt, wundert es mich dass ich bis jetzt keine Lösung gefunden habe und wir offensichtlich alles zu Fuß machen müssen. Evtl. liegt das aber halt auch daran, dass es nicht oft gebraucht wird oder die Anwendungsfälle zu speziell sind. Insbesondere die Tatsache, dass die Bankeinstellungen mit den HTTPS-HBCI Servern immer gepflegt werden müssen machen mich etwas stutzig, dass das wirklich alles z.zt. noch selber machen?!

Es scheint schon das ein oder andere zu geben. Aber alle Varianten haben große Nachteile oder man kommt garnicht erst dran.

Hast Du Links zu den Sachen die Du kennst?

Ja, hab Dir eine PN geschickt.

Nur am Rande: eine solches Vorhaben steht und fällt oft aus rein rechtlichen Gründen: wenn Du dieses Web-Interface nicht nur SELBST für Deine eigene Bank-Verbindung nutzen willst, sondern dieses Web-Interface potentiellen KUNDEN anbieten willst, die damit IHRE Bankgeschäfte erledigen können, wird schnell das Problem auftreten, dass es Deinen potentiellen Kunden gar nicht erlaubt ist, ihre Bankzugangsdaten (konkret: PIN, TANs) einem "Dritten" (Dir) zu geben, damit Du in deren Namen Aufträge ausführst.

Direkt "strafbar" macht sich damit wohl niemand (steinigt mich, falls ich falsch liege) - aber in dem Moment, wo einer dieser "Kunden" einmal PIN (und evtl. auch TAN) an Deine Web-App übergibt, verliert er sämtliche Haftungsansprüche für Online-Banking-Schäden...

-stefan-

@fkoehler: Habe Dein Original-Posting nicht richtig gelesen:



Ja.

1.) kontoblick.de - dort werden "im Namen des Kunden" Kontoumsätze von der Bank abgeholt und auf einem kontoblick-Server für weitere Auswertungen gespeichert. Oben genanntes "Problem" besteht dort allerdings nicht, weil das Abholen der Kontoauszüge in einem CLIENT(!)-seitigen Applet passiert - kontoblick erhält also "nur" die abgeholten Kontoumsatzdaten, nicht jedoch die HBCI-Zugangsdaten

2) sofortueberweisung.de - ein rotes Tuch für mich, deshalb verweise ich mal auf die Suchfunktion...

vielen dank für die infos stefan. das wäre in der tat ein problem mit der web-schnittstelle.

verstehe ich das richtig, dass kein problem besteht wenn wir hbci4java direkt in einer web-anwendung verwenden über welche die kunden dann ihre bankdaten abrufen die wir in unserer db speichern, also dass wir den pin nur durchreichen? oder ist es zwingend notwendig dass die applikation wirklich auf dem client rechner läuft?

mir fällt aber gerade ein, dass es dabei bei uns sowieso kein problem geben solle, da wir ausschliesslich "lesend" auf das konto zugreifen wollen um den aktuellen kontostand mit umsätzen zu ermitteln. wir wollen also keine anderen aktionen tätigen. ?!

Das verstehst Du falsch. Wenn EURE Web-Anwendung (die auf EUREM Server läuft) diese Daten von der Bank abruft, braucht ihr Nutzerkennung + PIN vom jeweiligen Kunden - streng genommen darf er beides nicht an Dritte weitergeben...

Die Lösung, das eigentliche ABHOLEN der Kontoumsätze von einer clientseitigen Applikation erledigen zu lassen und nur die empfangenen Kontoumsatzdaten dann an euren Server weiterzureichen, liegt außerhalb des "verbotenen Bereichs" (aus Sicht der Bank-AGB). Ob ihr aber eure potentiellen Kunden davon überzeugen könnt, ihre Kontoauszüge in eurer Datenbank abzulegen, ist ein anderes Problem...

Je nachdem, was eure Anwendung können soll, werden die Probleme aber noch größer: will ein Kunde z.B. eine Überweisung einreichen, müsste auch das über eine client-seitige Applikation erledigt werden. Ihr dürft höchstens die eigentlichen Überweisungs-Daten speichern (Empfänger, Betrag, VWZweck usw.), die euch die client-seitige Applikation "hinterum" übermittelt - aber auch das ist rein datenschutzrechtlich schon nicht mehr wirklich schön.

-stefan-

Ok, dann vergiss auch meinen Text bzgl. "Überweisungen"...

Wenn man jetzt als Anbieter dieser Webschnittstelle mit dem Kunden eine schriftliche Vereinbarung treffen würde, dass weder Anmeldename noch PIN noch TAN gespeichert werden, wäre dann der Onlinebanking-Kunde raus?

Denn andersherum gibt der Kunde bei Nutzung einer Onlinebankingsoftware und Speicherung der PIN auch seinen PIN weiter. Sollte eine solche Software mal gehackt oder durch Trojaner komprimittiert werden hat der Kunde ja auch ein Problem, oder?

Für mein Verständnis ändert dies am AGB-Bruch nichts. Wenn man seine Daten nicht weitergeben soll, dann ist es doch egal, ob diese beim Empfänger gespeichert werden, wenn man es doch tut.

Aber wie so oft. Theorie und Praxis. Solange nie ein Missbrauch auf dem Konto passiert, kann es dem Kunden egal sein, ob er "raus" ist. Es geht eh längst auf seine Kappe.

OK, dieser Aussage entnehme ich, dass man den PIN in stationär installierten Softwareprodukten ebensowenig speichern darf. Insbesondere, weil ja auch die elektr. Speicherung explizit in den AGB meistens ausgeschlossen ist.

Damit verhält sich dann m.E. eine solche Webschnittstelle die das Speichern von BKN+PIN garnicht erst anbietet und das auch im Hintergrund nicht tut sogar aus Sicht des Onlinebankingteilnehmers noch AGB konformer als eine stationäre Software. Insofern m.E. halb so wild und kein Argument gegen eine solche Schnittstelle. Zumindest würde ich mich als Anbieter einer solchen Schnittstelle davon nicht abhalten lassen.

@fkoehler: Ich/Wir würden sie trotzdem nutzen.

Ich geb' auch mal meine Meinung dazu ab:

Ich finde das lokale Speichern einer PIN, oder auch das "Durchleiten" der PIN über eine "vertrauenswürdige" Webseite persönlich nicht tragisch. Mit der PIN alleine kann man nichts anstellen und meine Kontoauszüge sind wirklich totlangweilig. Also was soll's.

Bei der TAN hingegen hört der Spaß auf. Auch wenn meine Programme (gezwungen durch User-Protest) eine Speicherungsmöglichkeit für TAN-Nummern anbieten, ich selbst nutze diese nicht. Ich hätte auch echt Bauchschmerzen wenn ich eine TAN auf einer fremden Web-Seite eingeben müsste. Das sollte man dann doch lieber lassen.

Die elektronische Speicherung ist per Sonderbedingungen verboten, ja. Ohne ausdrückliche Konfiguration des Kunden wird dies aber auch von Software wie zB Proficash garnicht vorgenommen.

Ich such hier auch keine Argumente gegen die Web-Schnittstelle. Ich persönlich würde sie einfach nicht nutzen, da ich mich damit nicht auskenne. Die Grundsatzdiskussion, was dem Kunden erlaubt ist und was er zB aus Bequemlichkeit trotzdem macht, gibt es ja schon wesentlich länger.

Eine Abfrage deines 'Gesamtengagements / Finanzstatus' ist doch sehr informativ.
- Zahlungskräftiger Kunde , oder nicht (Darlehen?)
- Überweisungen an Versicherungen rufen geradezu nach einer Beratung wo es etwas günstiger gibt
- Dauerauftrag mit Betreff 'Alimente'? oh oh, Lebenswandel
- Dauerauftrag an die 'TAZ' oh oh, linker chaot
etc, etc, etc